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THE MAILING DATE OF THIS COMMUNICATION. " 
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Art Unit: 2145 

DETAILED ACTION 
Claim Objections 

1 . Claim 1 is objected to because of the following informalities: improper form, i.e. 
more than one sentence indicated by more than one period. A properly written claim is a 
single sentence. Appropriate correction is required. 

2. Claim 1 is objected to because of the following informalities: "I claim" is recited 
the claim language. "I claim" can be a sub-heading under the title "Claims" but must not 
be recited in the claim itself. Appropriate correction is required. 

Claim Rejections - 35 USC §112 

3. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and orocess of 
f "2 ' ' m SUCh J" 1 ' C,ear ' Concise ' and exact terms as to enable any wSdSSKh? 
2 hJh P T a,n H' ° r f "t** * is most near, y con ^ted. to make and use the same and shalf 
set forth the best mode contemplated by the inventor of carrying out his invention. 

4. Claim 1 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply with 
the enablement requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to enable one skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and/or use the invention. 
Applicant's specification lacks description of the "Matrix Network Control System". The 
specification does not provides no insight as to network the Matrix Naming Structure is 
incorporated into or the control system that coordinates interaction with the Matrix 
Naming Structure. 
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5. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

SmiS 3 ^" Sl ? a " c ° nclude u with one or mor e claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

6. Claim 1 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite 
that it fails to point out what is included or excluded by the claim language. This claim 
an omnibus type claim. The following language renders the claim 1 an omnibus type 
claim "outlined in this patent [application] as my invention". 



in 
is 



Claim Rejections • 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

fortJ iKS^Mrf^^? inV T ti0n iS ^ identiCa " y diSCl0Sed or described as 

Tortn in section 102 of this title, if the differences between the subject matter souqht to be Datented and 

the prior art are such that the subject matter as a whole would have been obvious a time the 

ssns-ir H m ?. de ;°K a person havin9 ordinary skin in the art to v*S^S^Si^5;„. 

Patentability shall not be negatived by the manner in which the invention was made 

8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art 

2. Ascertaining the differences between the prior art and the claims at issue 
J. Resolving the level of ordinary skill in the pertinent art 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

9. Claim 1 is rejected under 35 U.S.C. 103(a) as being unpatentable over Ryan, 
USPN 6,412,014 B1 (hereafter referred to as Ryan) in view of Weider et al., USPN 
6,374,253 B1 (hereafter referred to as Weider). 
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1 0. Regarding claim 1 , Ryan taught a Matrix Network Control System and Matrix 
Naming Structure outlined in this patent application (abstract), the matrix naming 
structure (directory 7) specifically includes creating a matrix (dimension x = type of 
activity, dimension y = entity, column 5, lines 11-19), a collective structure containing 
sub-objects, that is represented by number(s), letter(s), or an alpha-numeric 
combination (directory 7, column 5, lines 20-23), separated by a space (separate by the 
space between lines), then combined with an identifying name, number, or alpha- 
numeric combination to form a root definition (column 5, lines 38-45); 

wherein the naming structure also includes developing branches (column 4, lines 
37-49) and forming aliases (column 5, lines 23-30); and 

wherein Matrix Control System specifically includes developing a network 
structure using the Matrix Naming Structure (column 4, line 63 - column 5, line 5), 
including the development of a Global Matrix (column 3, lines 52-61 ). Ryan does not 
specifically the using delimiters "|" character and "@" character. However, Weider 
taught using the delimiters T and "@" (column 7, lines 22-28). It would have been 
obvious to one of ordinary skill in the art at the time the invention was made that 
incorporating Weider's delimiters in Ryan's Internet Directory System would have 
provided Ryan's system greater flexibility. The motivation would have been to increase 
the number of characters which can be prescribed delimiters. 
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Conclusion 

1 1 . The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

a. Belissent et al., USPN 6,685,594 B1 : taught when a message having a 
new domain name is received, a directory server creates a corresponding entry 
in a directory for every component that does not already exist in the directory; 

b. William Wong, Accessing the Directory Database Using Distinguished 
Names: taught a Distinguished Name (DN) is a list of items, separated by 
commas, where each item is an attribute name followed by an equals sign (=) 
and a value; and 

c. Timothy A. Howes, The Lightweight Directory Access Protocol: X.500 Lite: 
taught that in LDAP and X.500 directory services entries are arranged in a tree 
structure and divided among servers in a geographical and organizational 
distribution. Entries are named according to their position in this hierarchy by a 
distinguished name (DN). 

1 2. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Patrice Winder whose telephone number is 571-272- 
3935. The examiner can normally be reached on Monday-Friday, 10:30 am-7:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Valencia Martin-Wallace can be reached on 571-272-6159. The fax phone 



Application/Control Number: 09/681 ,519 Paqe 6 

Art Unit: 2145 

number for the organization where this application or proceeding is assigned is 703- 
872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-freeU-^ 



Patrice Winder 
Primary Examiner 
Art Unit 2145 



March 1 1 , 2005 
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X.500 is the OSI directory service. X.500 defines the following components: 

- An information model-determines the form and character of information in the directory. 

- A namespace-allows the information to be referenced and organized. 

- A functional model-determines what operations can be performed on the information. 

- An authentication framework-allows information in the directory to be secured. 

- A distributed operation model-determines how data is distributed and how operations are carried out. 

The information model is centered around entries, which are composed of attributes. Each attribute has 
a type and one or more values. The type determines the attribute's syntax, which defines what kind of 
information is allowed in the values. 

Which attributes are required and allowed in an entry are controlled by a special objectClass attribute in 
every entry. The values of this attribute identify the type of entry (e.g., person, organization, etc.). The 
type of entry determines which attributes are required, and which are optional. For example, the object 
class person requires the surname and commonName attributes, but description, seeAlso, and others are 
optional. 

Entries are arranged in a tree structure and divided among servers in a geographical and organizational 
distribution. Entries are named according to their position in this hierarchy by a distinguished name 
(DN). Each component of the DN is called a relative distinguished name (RDN). Alias entries, which 
point to other entries, are allowed, circumventing the hierarchy. Figure 1 depicts the relationship 
between entries, attributes, and values and shows how entries are arranged into a tree. 

dlaa object / 

^[ \'m\m \ ... \ 

fae |iaue |\aua|...| 

Figure 1. X.500 information model 

The X.500 model is centered around entries composed of attributes that have a type and one or more 
values. Entries are organized in a tree structure. Alias entries can be used to build non-hierarchical 
relationships. 

Functionally, X.500 defines operations in three areas: search and read, modify, and authenticate. In the 
first category, the read operation retrieves the attributes of an entry whose name is known. The list 
operation enumerates the children of a given entry. The search operation selects entries from a defined 
area of the tree based on some selection criteria known as a search filter. For each matching entry, a 
requested set of attributes (with or without values) is returned. The searched entries can span a single 
entry, an entry's children, or an entire subtree. Alias entries can be followed automatically during a 
search, even if they cross server boundaries. 

In the second category, X.500 defines four operations for modifying the directory. The modify operation 
is used to change existing entries. It allows attributes and values to be added and deleted. The add and 
delete operations are used to insert and remove entries from the directory. The modify RDN operation is 
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used to change the name of an entry. 
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The final category defines a bind operation, allowing a client to initiate a session and prove its identity 
to the directory. Several authentication methods are supported, from simple clear-text password to 
public key-based authentication. The unbind operation is used to terminate a directory session. An 
abandon operation is also defined, allowing an operation in progress to be canceled. 

Each X.500 operation and result can be signed io ensure its integrity. Signing is done using the 
originating client's or server's public key. The signed request or result is carried end-to-end in the 
protocol, allowing integrity to be checked at every step. This guards against connection hijacking or 
modification by intermediate servers. Service controls can be specified that determine information such 
as how an operation will be carried out, whether aliases should be dereferenced, the maximum number 
of entries to return, and the maximum amount of time to spend on an operation. 

In X.500, the directory is distributed among many servers (called DSAs for Directory System Agent). 
No matter which server a client connects to, it sees the same view of the directory. If a server is unable 
to answer a client's request, it can either chain the request to another server, or refer the client to the 
server. 
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3. Overview of LDAP 
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LDAP assumes the same information model and namespace as X.500. It is also client-server based, with 
one important difference: there are no referrals returned in LDAP. An LDAP server must return only 
results or errors to a client. If referrals are involved, the LDAP server is responsible for chasing them 
down. This model is depicted in Figure 2, though the intermediate server shown is not required (i.e., an 
implementation could choose to have its DSA speak "native" LDAP). 



LDO> 


-4 


LDJP 




Client 




Seruer 






xsoo 

DSA 

LD <P chdn 



Figure 2. Relationship between LDAP and X.500 

The LDAP client-server model includes an LDAP server translating LDAP requests into X.500 requests, 
chasing X.500 referrals, and returning results to the client. 

The LDAP functional model is a subset of the X.500 model. LDAP supports the following operations: 
search, add, delete, modify, modify RDN, bind, unbind, and abandon. The search operation is similar to 
its DAP counterpart. A base object and scope are specified, determining which portion of the tree to 
search. A filter specifies the entries within the scope to select. The LDAP search filter offers the same 
functionality as the one in DAP but is encoded in a simpler form. 

The time and size limit service controls are included directly in the search request. (They are not 
included with the other operations.) The searchAliases search control and dereferenceAliases service 
control are combined in a single deref Aliases parameter in the LDAP search. The ASN.l [1 1] definition 
of the LDAP search request is shown in Figure 3. 



SearchRequest ::= [APPLICATION 3] SEQUENCE { 

baseObject LDAPDN, 

scope ENUMERATED { 

baseObject (0), 

singleLevel (1), 

wholeSubtree (2) 

>. 

derefAliases ENUMERATED { 
neverDerefAliases (0), 
dereflnSearching (1), 
derefFindingBaseObj (2), 
alwaysDerefAliases (3) 
}. 

sizeLimit INTEGER (0 .. Maxlnt), 
timeLimit INTEGER (0 .. Maxlnt), 
attrsOnly BOOLEAN, 
filter Filter, 

attributes SEQUENCE OF AttributeType 

Filter ::= CHOICE { 
and [0] SET OF Filter, 

g c ec c h 
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or [1] SET OF Filter, 
not [2] Filter, 

equality Match [3] Attribute Value Assertion, 
substrings [4] SubstringFilter, 
greaterOrEqual [5] Attribute ValueAssertion, 
lessOrEqual [6] Attribute ValueAssertion, 
present [7] AttributeType, 
approxMatch [8] Attribute ValueAssertion 

Figure 3. ASN.l for the LDAP search operation 



The LDAP search operation offers similar functionality to DAP search. It combines search parameters 
and service controls and simplifies the filter encoding. 

The LDAPDN and AttributeType components of the search are encoded as simple character strings using 
the formats defined in RFC 1779 [5] and RFC 1778 [2], respectively, rather than the highly structured 
encoding used by X.500. Similarly, the value in an AttributeValueAssertion is encoded as a primitive 
OCTETSTRING, not a more structured ASN.l type. The structure is reflected in the syntax of the 
encoded string, not in the encoding itself. 

The results of an LDAP search are sent back to the client one at a time, in separate searchEntry packets. 
This sequence of entries is terminated by a final searchResult packet that contains the result of the 
search (e.g., success, a size or time limit was exceeded, etc.). Having a final terminator packet allows 
clients and servers to stream results more easily, handling one entry at a time. This is especially useful 
in memory-constrained environments where holding the collection of all entries from a large search is 
not possible. 

The X.500 list and read operations are not included in LDAP. Instead, they are emulated with the LDAP 
search operation. Read is emulated by a base object search of the entry to read, with a filter testing for 
the existence of the objectClass attribute. Every entry is required to have an object class and must match 
this filter. List is emulated by a one level search of the entry to list, also with a filter testing for the 
existence of the objectClass attribute. If the ability to distinguish alias children from other children (a 
feature provided by X.500 list) is desired, the objectClass attribute can be retrieved and examined for a 
value of alias. 

The LDAP modify operation also differs slightly from its DAP counterpart. In DAP, four kinds of 
changes can be made: entire attributes can be added or deleted; individual values can be added or 
deleted. These capabilities require a client to read an entry before attempting a modify (e.g., when 
adding a value, to discover whether an add attribute or add value is required). 

In LDAP, we simplified the semantics of modify by supporting three operations: add values; delete 
values; and replace values. If a request is made to add values to an attribute that does not exist in the 
entry, the attribute is created automatically. If a request is made to delete the last value of an attribute, 
the entire attribute is deleted. An attribute can also be deleted by specifying a delete values operation' 
without specifying any values. Finally, the replace values construct is used to make an attribute contain 
the given values after the modify. The LDAP server takes care of translating the replace request into the 
necessary sequence of modify, add, and delete operations required by X.500. 

The LDAP bind operation supports a subset of X.500 bind functionality. It allows only simple 
authentication, consisting of a clear-text password, and Kerberos version 4 authentication [6], which 
translates into an X.500 external authentication method. The LDAP bind operation includes a choice of 
credentials, allowing for future expansion of available authentication methods. 
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The DAP unbind, abandon, modify RDN, add and delete operations are virtually identical to their DAP 
counterparts. 
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Accessing the Directory Database Using Distinguished Names 



A distinguished name (DN) is a text representation of an entry in the 
directory server database. A DN is a list of items, separated by commas, 
where each item is an attribute name followed by an equals sign 
character (=) and a value. For example, cn=Bill Wong, ou=Win NT Labs, 
c=US specifies a database entry with a common name (cn) of Bill Wong' 
in an organizational unit (ou) of Win NT Labs in the country (c) of the 
United States (US). You use a DN to access entries in the directory 
database. Every item in the database has a unique DN, including the 
directory server and any other servers that it communicates with (e.g., the 
certificate server). 

When you install and configure a directory server, you must specify 
several DNs. These entries include the root that will be common to all 
entries in the database, the directory server, the original administrator, " 
and any other servers the administrator uses during the directory server 
installation, such as the certificate server or any replica directory servers. 
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